Some additions and changes have been made to the software in this development package. The following list describes these changes along with some information on using the Thread Manager.
1) The big change: The Thread Manager is now available for both 680x0 and Power Macintosh platforms. This version contains the Thread Manager shared library which is what power applications call to use the Thread Manager. Using the native PPC Thread Manager does require compiling your code native for Power Macintosh machines. Read the READ ME for more information on how to compile your application using the new shared library. You'll find all you need in the folder named "Compiler Stuff". Also included is an updated version of the documentation that includes all information about the Power Thread Manager.
2) The following bug fixes have been made to the 2.0.1 version of the Thread Manager.
--> v2.0.1 Fixed a bug in QuickDraw on Mac IIci class machines (ROM version 0x67C) which would inadvertantly cause stack/heap collision crashes when the application was calling QuickDraw routines with a low stack space. This fix applies only to System 7.1 or later. If users of System 7.0 or 7.0.1 are experiencing problems related to QuickDraw & stack/heap collisions, they should update their systems to 7.1 or later as these systems require the 7.1 version of QuickDraw to fix the problem.
--> v2.0.1 Fixed a problem when an application quit with live threads, the native PowerPC thread termination routines (if they existed) were being called from the 68K context and not the PPC context, thus causing a crash.
--> v2.0.1 Fixed a problem with the :CIncludes:Threads.h header file. This file and MPW CFront (C++) did not get along due to typedef incompatibilities.
--> v2.0.1 Fixed a problem with the Threads.h header regarding an extraneous comma in the gestalt enum structure which caused warnings during a compile.
--> v2.0.1 Native PowerPC code has been compiled with PowerPC only instructions.
--> v2.0.1 The ThreadsLib.xcoff link library is now much smaller so it uses less disk space.
--> v2.0 Fixed a bug with VM and Thread Manager interaction. The Thread Manager globals would sometimes be paged out if VM got into a thrashing state.
--> v2.0 Fixed a bug where the Thread Manager was disposing the running thread upon exiting the application. This had very bad effects on the application that was quiting.
3) Mode32 version 1.2 and the Thread Manager are incompatible.
4) The source level debugger, VoodooMonkey has been updated to version d23.
5) There is an incompatibility with the VoodooMonkey DebuggerINIT and threaded PowerPC applications. In order to run a threaded PowerPC application, you must remove the VoodooMonkey DebuggerINIT.
6) New examples. The same old 680x0 examples are included in this package as well as some simple PowerPC Thread Manager examples.
7) There is a bug in the Traffic Simulation sample application with regard to custom context switchers. The custom context switchers in the application assume that register A5 points to the application globals, when in fact, it is not guaranteed to. The author of this application has been publicly chastised for not following the Thread Manager documentation about custom context switchers and A5. The fix to the code is left as an exercise for the reader.
8) There are two known bugs in the SortPicts sample applciation. The first problem has not been fully tracked down, but appears to be related to an unlocked handle. The problem manifests itself mostly when the about box is brought up and the picture starts to sort. In addition, SortPicts does not run in 24-bit mode due to the use of a non-StripAddressed handle while accessing GWorld data.
9) General Thread Manager information:
-- The caller of DisposeThread can decide if the thread is reclaimed in the thread pool. If the thread calling DisposeThread is a preemptive thread, the disposed of thread is ALWAYS reclaimed in the thread pool to prevent Memory Manager calls from being called at preemptive thread time. When a thread RTSes, it will not be reclaimed into the thread pool unless it is a preemptive thread (for the above reason).
-- Thread termination routines can rely on register A5 being valid when they are called. Thread termination routines can make all the thread calls a thread can make. The thread result is set before the thread termination routine is run.
-- For those of you who use SIOW applications, you need to preload/lock all your code resources for the application to run correctly. No details on why this overkill is needed, but if you do this, it works.
-- A ThreadTaskRef is unique for each application launched and does not change during application execution.
-- Allocation from a thread pool works as 'best fit' for the new thread stack size unless the new thread creation option, kExactMatchThread, is used.
If you have any bug reports or comments, please don’t hesitate to link or write. You can contact us through the following:
Alink: DEVSUPPORT (provided you have Apple developer support access)
or
Eric Anderson: ALink: Eric3, AOL: ERICTHREE
...or place your comments in the Developer Talk bulletin boards on AppleLink, the internet, Compuserve, AOL, or some other public discussion area.
